This commit ports the latest state of scalar_hash kernels without
pulling a long development history.

This kernel is an element-wise function that uses an xxHash-like
algorithm, prioritizing speed and not suitable for cryptographic
purposes. The function is implemented by the `FastHashScalar` struct
which is templated by the output type (which is assumed to be either
UInt32 or UInt64, but there is no validation of that at the moment).

The benchmarks in scalar_hash_benchmark.cc uses the hashing_benchmark.cc
file as a reference (in cpp/src/arrow/util/), but only covers various
input types and the key hashing functions (from key_hash.h).

The tests in scalar_hash_test.cc use a simplified version of hashing
based on what is implemented in the key_hash.cc. The idea being that the
high-level entry points for high-level types should eventually reach an
expected application of the low-level hash functions on simple data
types; the tests do this exact comparison. At the moment, the tests pass
for simple cases, but they do not work for nested types with non-trivial
row layouts (e.g. ListTypes).

Issue: ARROW-8991
Issue: apacheGH-17211

This commit pulls the latest changes to key_hash.h and implementations
in light_array without the burden of a long development history.

The only change in key_hash.h is the addition of a friend function which
is used in scalar_hash_test.cc.

Changes in light_array.[h,cc] are to accommodate two scenarios: (1) the
use of ArraySpan, which was introduced after light_array was written;
and (2) the need for a KeyColumnArray to allocate data for the purposes
of interpreting (or decoding) the structure of a nested type.

The main reason for the 2nd scenario is that a ListArray may have many
values represented in a single row which should be hashed together;
however, if the ListArray has a nested ListArray or other type, the row
may have further structure. In the simplest interpretation, only the
highest-level structure (the "outer" ListArray) needs to be preserved,
and any further nested structures must be explicitly handled by custom
kernels (or any future options, etc. that are upstreamed into Arrow).

In trying to efficiently interpret complex nested types, ArraySpan can
be useful because it is non-owning, thus the main reason for the 1st
aforementioned scenario.

Although unfinished, any tests added to light_array_test.cc should
accommodate the 2 scenarios above.

This commit includes changes to register a new compute function without
the burden of a long development history.

The change to cpp/src/arrow/CMakeLists.txt includes scalar_hash.cc in
compilation as it is used by the new Hash64 function defined in
api_scalar.[h,cc].

The change to cpp/src/arrow/compute/kernels/CMakeLists.txt includes
scalar_hash_test.cc in compilation for tests and it also adds a new
benchmark binary that is implemented by scalar_hash_benchmark.cc.

The registry files are updated to register the kernel implementations in
scalar_hash.cc with the function definitions in api_scalar.[h,cc].

Finally, docs/source/cpp/compute.rst adds documentation for the Hash64
function.

Issue: apacheGH-17211
Issue: ARROW-8991

This commit includes additions to the general hashing benchmarks that
cover the use of hashing functions in key_hash.h without carrying the
burden of a long dev history.

Some existing benchmark names were changed to distinguish between the
use of Int32 and Int64 types, new benchmarks were added that use the
functions declared in key_hash.h. The reason the new benchmarks are
added is because it is claimed they prioritize speed over cryptography
as they're primarily used for join algorithms and other processing
tasks, which the hashing benchmark can now provide observability for.

Issue: apacheGH-17211
Issue: ARROW-8991

This is primarily to make the next commit a bit more focused.

Previous commits tried to add allocation mechanisms to KeyColumnArray to
accommodate arbitrarily nested types. While some allocation is necessary
to accommodate arbitrarily nested types, the work is being split into
incremental steps and scope is being reduced to the straightforward
nested types.

Specifically, we want to support: ListArray, StructArray, and MapArray.
We **only** support these types if they contain primitive types (e.g.
List<int8> not List<List<int8>>, or Map<int64, float32> not Map<string,
int32>).

The difficulty with nested types beyond the first level is that multiple
buffers of offsets must be accommodated and that support requires
changes that either: (1) will propagate through key_hash code or (2)
requires a (temporary) allocation of an array that flattens offsets into
a single offset buffer.

Needed to add a check when constructing a KeyColumnArray for a ListArray
that the element type of the ListArray is primitive.